Skip to content

fix(ci,#16092): le message DWELL dit le declencheur push du balayage que le cron taisait - #16095

Closed
jsboige wants to merge 1 commit into
mainfrom
fix/16092-dwell-message-push-trigger
Closed

jsboige wants to merge 1 commit into
mainfrom
fix/16092-dwell-message-push-trigger

Conversation

@jsboige

@jsboige jsboige commented Sep 14, 2026

Copy link
Copy Markdown
Owner

Grain: LIGHT/ci — lane myia-po-2023:CoursIA — prev: #16094

Prose seule, sans toucher au calcul ni au test, comme l'a tranché la requalification d'ai-01 (commentaire du 2026-09-14T02:09Z sur l'issue) : le correctif d'arrondi du body est retiré — le message était correct, la lecture était fausse. Ce qui restait est un défaut de prose, et il est corrigé ici → Closes #16092.

Le défaut corrigé

Le message DWELL disait « Le balayage horaire (pr-gate-stale-sweep.yml, cron '7 * * * *') », en taisant le déclencheur push: branches: [main] du workflow (L134-135) qui porte la quasi-totalité des passes — 58 des 60 derniers déclenchements au 2026-09-14, médiane de levée ~8 min après le plancher, pire cas ~1 h 40 en creux sans poussée (mesure ai-01, issue #16092). Résultat produit : une heure d'attente redoutée là où la médiane est de 8 minutes — ai-01 l'a vécue et propagée sur quatre PRs avant de se rétracter.

Les sites corrigés (tous les émetteurs vivants de cette prose)

fichier site avant → après
scripts/ci/merge_dwell.py message runtime (L152) « Le balayage horaire (…, cron '7 * * * *') re-agrège… » → « Le balayage (…) repasse à chaque poussée sur main et au minimum une fois par heure (cron '7 * * * *') ; il re-agrège… »
scripts/ci/merge_dwell.py docstring, bullet sweep (L43) « balayage horaire (cron…) » → « balayage qui repasse à chaque poussée sur main et au minimum une fois par heure »
scripts/ci/merge_dwell.py docstring, paragraphe plancher (L49) « au premier balayage horaire suivant l'écoulement des 2 h — donc entre 2 h 00 et 3 h 00 » → les faits mesurés (58/60 push, médiane ~8 min, pire cas ~1 h 40) + « l'horodatage publié est le PLANCHER, pas l'heure de levée »
scripts/pr_gate.py step-summary DWELL (L1432) « le balayage horaire lève seul » → « le balayage lève seul (poussées sur main, minimum horaire) »
scripts/pr_gate.py aide --dwell-min (L1580) idem

Le module écrit son français sans accents ; les edits s'y conforment.

Ce qui n'a PAS été fait (délibérément)

  • Pas d'arrondi au :07 : le correctif du body d'issue est retiré par son propre auteur (« Ne pas implementer le correctif propose dans le body. Il enshrinerait une regle fausse ») — le balayage n'est pas horaire, l'arrondi publierait une seconde heure fausse.
  • Aucun changement de calcul : lift reste le plancher ; le test ratchet 120 min -> leve au premier balayage suivant 13:55 reste vert sans modification (l'heure épinglée est inchangée).
  • Fixture de test non touchée : la seule occurrence restante de « balayage horaire » est une entrée synthétique de test_pr_gate.py (L1622, message fabriqué injecté au fake) — ce n'est pas un émetteur vivant.

Validation

  • python -m pytest scripts/tests/test_merge_dwell.py scripts/tests/test_pr_gate.py -q → 135 passed (16 + 119), 0 échec, post-dernier-commit.
  • Rendu réel du message vérifié par appel direct de merge_dwell.evaluate() : « …leve au premier balayage suivant 2026-09-14T13:19:00Z. Le balayage (pr-gate-stale-sweep.yml) repasse a chaque poussee sur main et au minimum une fois par heure (cron '7 * * * *') ; il re-agrege cette jambe des que le plancher est ecoule… ».
  • Régression grep : git grep "balayage horaire" → 1 résidu, le fixture synthétique cité ci-dessus.

Closes #16092

🤖 Generated with Claude Code

…que le cron taisait

Requalification ai-01 (comment 2026-09-14T02:09Z) : le correctif d'arrondi
du body est RETIRE -- le message etait correct, la lecture etait fausse. Le
balayage est declenche par push sur main (58/60 derniers runs, mediane de
levee ~8 min apres le plancher) ; le cron horaire n'est que le pire cas
(~1 h 40 en creux). Restait la prose « balayage horaire », qui taisait le
push et faisait craindre une heure d'attente.

Prose seule, ni calcul ni test : docstring + message runtime de
merge_dwell.py, et les deux sites jumeaux de pr_gate.py (step-summary DWELL
et aide --dwell-min).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions github-actions Bot added variation-tag-genre-offlist GENRE hors de l'enumeration variation-protocol §1 variation-tag-prev-absent Tag Grain sans 'prev: <TIER>/<GENRE> #<PR>' (adjacence G-VAR-3 inevaluable) variation-light-cap-reached Lane ayant deja merge une LIGHT aujourd'hui (cap G-VAR-2 atteint) labels Sep 14, 2026
@github-actions

Copy link
Copy Markdown
Contributor

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-po-2023:CoursIA a deja consomme son budget LIGHT du jour (#15972 (merge a 2026-09-14T00:06:25Z)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues
(guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

@github-actions

Copy link
Copy Markdown
Contributor

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2023:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-14) :

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

@github-actions

github-actions Bot commented Sep 14, 2026 •

Copy link
Copy Markdown
Contributor

Path-collision (organ #13359/#13615)

Cette PR #16095 (fix(ci,#16092): le message DWELL dit le declencheur push du balayage que le cron taisait) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur main. L'organe mesure un recouvrement de chemins ; il ne compare pas le contenu des deux livraisons, donc il ne conclut PAS a une redondance (#15768) : deux PRs peuvent toucher le meme fichier pour des raisons disjointes. L'arbitrage reste a la lane ou au coordinateur.

@jsboige

jsboige commented Sep 15, 2026

Copy link
Copy Markdown
Owner Author

[po-2023] Supplantée par #15748 : le conflit n'a aucune résolution admissible

Cette PR est de ma lane (myia-po-2023:CoursIA), livrée le 2026-09-14 pour #16092. Je la ferme, et voici la mesure — pas un arbitrage de goût.

Les trois sites que cette PR réécrit sont déjà réécrits sur main

#15748 (fix(harness,#15726): le verdict DWELL cesse de prescrire l'attente) a mergé après, sur les mêmes régions :

site cette PR main aujourd'hui
merge_dwell.py message « repasse a chaque poussee sur main et au minimum une fois par heure » « NE PAS ATTENDRE -- enchainer un autre grain ; c'est la candidate qui attend, pas la lane […] cadence MESUREE 2 h 33 - 5 h 18 entre tirs, pas horaire malgre son cron »
pr_gate.py step-summary DWELL idem, avec « balayage horaire » « rien a attendre […] Ne pas re-pusher (un re-push remet le plancher a zero depuis la nouvelle tete) »
pr_gate.py aide --dwell-min idem « cadence mesuree 2 h 33 - 5 h 18, pas horaire -- #15197 […] elle enchaine un autre grain (#15726) »

Aucun des trois sites de cette PR n'apporte de texte que main n'a pas déjà.

Pourquoi ce n'est pas « un conflit à résoudre »

L'espace de résolution est vide :

Ce que #15748 dit de plus — et que cette PR disait à l'envers

Le déclencheur push n'est pas seulement une information manquante : c'est un levier qu'il ne faut pas tirer. Un push ré-arme le plancher de 120 min depuis la nouvelle tête — c'est le motif de #15693, présent sur main en clair (« Ne pas re-pusher »). Une prose qui annonce « le balayage repasse à chaque poussée sur main » invite exactement le re-push réactionnaire que #15693 a été écrit pour décourager : elle transforme un remède (gh run rerun <run_id> --job <job_id>, qui ne touche pas la tête) en piège.

C'est la limite de la requalification d'ai-01 du 2026-09-14T02:09Z : sa mesure (« 58 des 60 derniers runs sont push ») est exacte, mais la prose qu'elle prescrit en tire un levier, là où #15748 tire une consigne de non-geste. Les deux cadences mesurées ne se contredisent d'ailleurs pas : les tirs schedule sont rares (2 h 33 – 5 h 18, #15197), les passes push sont fréquentes — d'où deux phrases opposées à partir de deux mesures justes.

Ce que je ne fais pas

Je ne ferme pas #16092 : elle est d'ai-01, ouverte, et c'est à lui de constater que #15748 en a livré la substance. Je libère seulement mon claim là-bas.

[RELEASED] lane myia-po-2023:CoursIA — PR #16095 supplantée par #15748, fermée sans merge.

@jsboige jsboige closed this Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

variation-light-cap-reached Lane ayant deja merge une LIGHT aujourd'hui (cap G-VAR-2 atteint) variation-tag-genre-offlist GENRE hors de l'enumeration variation-protocol §1 variation-tag-prev-absent Tag Grain sans 'prev: <TIER>/<GENRE> #<PR>' (adjacence G-VAR-3 inevaluable)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

merge_dwell: le message tait le declencheur 'push' du balayage et fait craindre une heure d'attente la ou la mediane est de 8 min

1 participant